Serial communication of information has long existed in many digital applications. For example, many computer networks include a number of stations connected to a serial network, where each of the stations communicates serial information to other stations along the network. Moreover, some systems communicate serial information over different types of media. For example, digitized serial telephone signals are commonly communicated over contemporary fiber optic systems. As another example, digital radio transceivers communicate serial information by converting the serial data stream into an RF signal for transmission/receipt between communicating transceivers. Numerous other examples of serial communication are readily appreciated by a person having skill in the art.
FIG. 1 illustrates a typical prior art format for communicating serial information between two devices (irrespective of the communication medium used by the devices). Specifically, FIG. 1 illustrates a sequence of bytes commencing with a stream of HEADER bytes followed by a stream of DATA bytes. Typically, the number of HEADER bytes (shown as M) is considerably less than the number of DATA bytes (shown as N). As known in the art, the HEADER bytes typically present information concerning the upcoming DATA bytes; however, the HEADER bytes may provide some type of communication control that does not relate to the upcoming DATA bytes. The information provided by the HEADER byte may directly occur from the bits of the byte or, alternatively, may provide an address for determining the functions performed in response to the byte.
The first HEADER byte (shown as HEADER.sub.1) is known as a header identification byte. The header identification byte often indicates the total number of HEADER bytes in the HEADER stream. This indication may be provided directly by the lead HEADER byte, that is, by dedicating a certain number of bits to give a binary representation of the number of HEADER bytes. For example, three bits in HEADER.sub.1 could be set aside to indicate that the HEADER stream includes anywhere from one to eight (i.e., 2.sup.3 =8) HEADER bytes. As an alternative, the header identification byte may provide an address or indication of a look-up feature which, upon consulting a look-up table, indicates the number of subsequent HEADER bytes. In either instance, once the number of HEADER bytes are known, a count increments (or decrements) until the byte count is satisfied, thereby indicating that the end of the HEADER byte stream has been received. Note also that the HEADER identification byte may itself indicate a control function to be performed, either in addition to, or in lieu of, identifying the number of immediately following HEADER bytes.
Although not shown, a TRAILER byte may immediately follow the sequence of HEADER bytes (i.e., HEADER.sub.1 through HEADER.sub.M). This TRAILER byte may be used to indicate the end of the HEADER sequence, and also may provide error correction information pertaining to the HEADER sequence.
The DATA bytes of FIG. 1 terminate with a last DATA byte of information (i.e., DATA.sub.N). As known in the art, one technique for defining such a termination is including a TRAILER byte which immediately follows the end of the stream of DATA bytes. The TRAILER may include error correction information, such as parity or the like. Although shown as a single byte, such information may comprise more than one byte. An alternative technique for terminating a DATA stream simply provides a fixed number of DATA bytes. This fixed number is typically embedded in the HEADER bytes, or is established under a specified protocol. Thus, a device receiving a stream of bytes may receive and decode the byte count, thereby indicating how many DATA bytes will follow the HEADER bytes. Consequently, as each DATA byte is received, a count increments (or decrements) until the byte count is satisfied, thereby indicating that the end of the DATA byte stream has been received.
FIG. 2 illustrates a block diagram of an example of devices which communicate serial information between one another. Particularly, FIG. 2 illustrates a first and second transceiver indicated at 10a and 10b, respectively. For purposes of FIG. 2, transceivers 10a and 10b are assumed to be identical in structure. Accordingly, for explanatory purposes, the designation "a" is used for each component described with respect to transceiver 10a, while the designation "b" is used for each like-component described with respect to transceiver 10b. Thus, the structural description set forth below with respect to transceiver 10a applies equally to transceiver 10b. Note that transceivers 10a and 10b are vastly simplified for purposes of exemplifying the present invention in a given context and, hence, should be understood to include numerous other components as known in the art.
Transceiver 10a includes a controller 12a for digital signal processing, as well as for controlling various components within transceiver 10a. As known in the art, transceiver 10a includes both a transmitter 14a and a receiver 16a. Specifically, controller 12a is coupled to provide digital signals to a digital-to-analog (D/A) conversion circuit 18a. D/A conversion circuit 18a converts the digital signals, and provides the resulting analog signals to transmitter 14a. Transmitter 14a includes known amplifier circuitry, and is coupled to an antenna 19a for transmitting radio signals to transceiver 10b. Antenna 19a is also coupled to provide analog signals it receives to receiver 16a. Receiver 16a is coupled to an analog-to-digital (A/D) conversion circuit 20a. A/D conversion circuit 20a converts the analog signals, and provides the resulting digital signals to controller 12a.
Transceivers such as transceiver 10a and 10b may be used in a multitude of applications. One example is communicating telephone signals as in the telecommunications art. For example, a pair of transceivers may dedicate one channel to communicate known voice signals, such as in a DS3 format. As known in the art, a DS3 format communicates 672 DS1 signals (e.g., a DS1 is a typical voice line, such as that from a single telephone).
In addition to voice signals, known transceivers communicate so-called overhead data between one another. Overhead data is communicated between transceivers on a channel independent of the channel communicating the DS3 format signals. The overhead data includes status (or performance) data pertaining to the transceivers. This status data may be transmitted as a sequence of DATA bytes as described in connection with FIG. 1, above. For example, transceiver 10a may communicate performance data to transceiver 10b indicating that transceiver 10a includes alarm functionality. Other examples of status data include the status of various functions of a transceiver, such as whether a particular channel is on-line or off-line, or whether a particular alarm has been activated, et cetera. The ability to communicate this status data is helpful because a person located at transceiver 10a can obtain status data pertaining to transceiver 10b without having to travel to the often remote location of transceiver 10b.
The overhead data also includes control data. This control data is used for activating a function or operation at the receiving transceiver. For example, control data may be used to switch a relay connected to the receiving transceiver. Accordingly, equipment (e.g., air conditioner) may be connected to this relay and, hence, controlled from a remote distance by the transmitting transceiver. The control data, like the status data, may also be transmitted as the DATA bytes described in connection with FIG. 1, above. Note, however, in the prior art, only a single stream of either status or control may be transmitted at one time. Thus, in the prior art, the DATA bytes for a given overhead stream are either all status DATA, or are all control DATA.
Note that each of the communicated signals described above may be simultaneously bi-directional. Thus, while transceiver 10a transmits a DS3 signal to transceiver 10b, transceiver 10b may simultaneously transmit a different DS3 signal back to transceiver 10a. Typically, these simultaneous transmissions are accomplished over different frequencies so as to avoid interference with one another. Note that the overhead data (i.e., status and control) also may be simultaneously communicated between transceivers.
For transceivers used in telecommunications applications, it has become known to include an automatic power control (APC) function between transceivers. The APC function operates such that a receiving transceiver senses the voltage level of the signals (both voice and overhead) it receives from a transmitting transceiver. If the voltage level approaches an unacceptably low value, the receiving transceiver communicates an APC control signal to the transmitting transceiver. The APC control signal adjusts the amplifier gain control (e.g., a given value of dB) on the transmitting transceiver. Because the signal is a control signal, it may be communicated as the control data described above.
One significant limitation in communicating APC control arises in the prior art when the number of status DATA bytes is large and/or the transmission rate of the status DATA bytes is slow. In this instance, the APC control byte(s) may arrive too late at the transmitting transceiver to have their intended effect. Consider the example of transceiver 10a and transceiver 10b. Suppose transceiver 10a is communicating a first DATA stream of either status DATA or control DATA (in the format shown in FIG. 1) to transceiver 10b. As transceiver 10b receives the first DATA stream, it senses the voltage level of the incoming signals. Assuming these levels are below acceptable standards, transceiver 10b must communicate an APC control signal to transceiver 10a so that transceiver 10a will increase its output power. As stated above, however, the transceivers can simultaneously communicate to one another. Thus, suppose that transceiver 10b, although having determined that an APC signal should be sent, is currently in the process of sending its own stream of status DATA to transceiver 10a. Because of the required format of FIG. 1, that is, only one type of DATA in an entire stream of DATA bytes, transceiver 10b must wait until the last of the current status DATA bytes have been sent before it can insert the APC control information (i.e., control DATA) into the next DATA stream. This condition is imposed because transceiver 10a expects to receive only one type of DATA bytes in a given stream (defined by an initial HEADER and ending with a TRAILER). Thus, transceiver 10b cannot immediately send the control DATA bytes. Indeed, if transceiver 10b immediately transmitted the control DATA bytes (before completing its second stream), transceiver 10a would wrongfully interpret the bytes as status DATA bytes, possibly causing an anomalous result.
Given the above, if the status DATA stream is lengthy (or slow), by time it is fully transmitted, and the APC control is transmitted in the next DATA stream, a significant delay occurs before transceiver 10a receives the APC control signal and adjusts its output power. If this delay is lengthy, the adjustment may occur at a time when communications have already been lost. Alternatively, by time transceiver 10a makes the adjustment, it may no longer be necessary, or may not be the proper amount.
One solution to this prior art problem is to include another medium (e.g., an additional channel) for communicating only the APC control information. Such a solution, however, significantly increases costs and complexity.
It is therefore an object of the present invention to provide an improved serial communication format and methodology for communicating control information in advance of completing the transmission of status information, wherein communication of both control and status information is along the same medium.
It is a further object of the present invention to provide such a format and methodology for efficiently controlling the automatic power control of a transceiver.
It is a further object of the present invention to provide such a format and methodology for discerning between control data and non-control data by transmitting an identification byte which is unique from all other data bytes.
It is a further object of the present invention to provide such a format and methodology for discerning between control data and non-control data by transmitting an identification byte having a selected bit set to a level opposite that of all other transmitted bytes.
It is a further object of the present invention to provide such a format and methodology for discerning between control data and non-control data by evaluating only selected bytes to determine if they are identification bytes.
Still other objects and advantages of the present invention will become apparent to those of ordinary skill in the art having reference to the following specification together with its drawings.